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Mail Stop Appeal Brief - Patents 
Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 

Sir: 

This is an appeal from the final rejection of the Examiner dated June 7, 2007, 
rejecting claims 1-7 and 13-16. 

REAL PARTY IN INTEREST 

The real party in interest in the present appeal is Sprint Communications 
Company L.P., assignee of the entire right, title, and interest in the present application. 
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RELATED APPEALS AND INTERFERENCES 



There are no related appeals or interferences known to appellant, the appellant's 
legal representative, or assignee which will directly affect or be directly affected by or 
have a bearing on the Board's decision in this appeal. 

STATUS OF CLAIMS 

The status of the claims is as follows: 

Claims allowed: none. 

Claims objected to: none. 

Claims rejected: 1-7 and 13-16. 

Claims withdrawn: 8-12 and 17-21. 

Claims canceled: none. 
The claims being appealed are: 1-7 and 13-16. 

STATUS OF AMENDMENTS 

All amendments submitted by Appellant have been entered. 

SUMMARY OF CLAIMED SUBJECT MATTER 

The present invention relates in general to distribution of protected (e.g., 
licensed) digital content over computer networks such as the Internet, and, more 
specifically, to making content items available via multiple digital rights management 
(DRM) systems and methods and to selection of a compatible DRM method for 
distributing content items from a target server to a client (page 1, lines 16-20). 
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As defined by claim 1, the invention comprises a method for initiating delivery 
of a digital rights management (DRM) encoded content item (e.g., items 12 and 13 in 
Figure 1) over a digital network (e.g., Internet 15 in Figure 1) between a client 16 and a 
target server 10. The client 16 identifies a link to target server 10 for accessing DRM 
encoded content item 12 (page 4, lines 11-12). The target server 10 is capable of 
providing DRM encoded content item 12 in a plurality of respective DRM methods (page 

4, lines 16-18). The client 16 initiates a network session with target server 10 (step 21 in 
Figure 2; and page 5, lines 10-16). The client 16 sends an offer message to target server 
10 containing a list of at least one supported DRM method (step 22 in Figure 2; and page 

5, lines 16-21). The target server 10 sends an answer message to client 16 containing a 
corresponding answer list 1) indicating whether each DRM method listed in said offer 
message is supported by said target server, and 2) providing a respective network address 
of a DRM license server for each supported DRM method (step 23 in Figure 2; page 5, 
lines 21-24; and page 6, lines 1-18). The client 16 selects a supported DRM method from 
the answer list (step 24 in Figure 2; and page 5, lines 25-26). The client 16 obtains a 
DRM license using the respective network address listed for the selected DRM method 
(step 25 in Figure 2; and page 5, lines 26-28). The target server 10 delivers the DRM 
encoded content item 12 to client 16 using the selected DRM method (step 26 in Figure 2; 
and page 5, line 28 to page 6, line 2). 

As defined in claim 13, the invention comprises software for distribution of 
digital rights management (DRM) encoded content items (e.g., items 12 and 13 in Figure 
1) over a digital network (e.g., Internet 15 in Figure 1) between a client 16 and a target 
server 10, wherein target server 10 is capable of providing DRM encoded content item 12 
in a plurality of respective DRM methods (page 4, lines 16-18). The software is 
embodied on a computer readable medium and, when executed by client 16, is operable to 
select a link to target server 10 for accessing a desired DRM encoded content item 12 
(page 4, lines 11-12). The software initiates a network session with target server 10 (step 
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21 in Figure 2; and page 5, lines 10-16). The software sends an offer message to target 
server 10 containing a list of at least one supported DRM method (step 22 in Figure 2; 
and page 5, lines 16-21). The software receives an answer message from target server 10 
containing a corresponding answer list 1) indicating whether each DRM method listed in 
said offer message is supported by said target server, and 2) providing a respective 
network address of a DRM license server for each supported DRM method (step 23 in 
Figure 2; page 5, lines 21-24; and page 6, lines 1-18). The software selects a supported 
DRM method from the answer list (step 24 in Figure 2; and page 5, lines 25-26). The 
software obtains a DRM license using the respective network address listed for the 
selected DRM method (step 25 in Figure 2; and page 5, lines 26-28). Then the software 
retrieves DRM encoded content item 12 from target server 10 using the selected DRM 
method (step 26 in Figure 2; and page 5, line 28 to page 6, line 2). 

None of the claims contain either a means plus function or a step plus function 

element. 

GROUNDS OF REJECTION TO BE REVIEWED 

1. Whether claims 1 and 13 are unpatentable under 35 U.S.C. § 103(a) as being 
unpatentable over Lockhart et al in view of Haukka et al. 

ARGUMENT 

Rejection of Claims 1 and 13 under 35 USC 103(a) 

Claim 1 

Claim 1 recites, inter alia, that the target server is capable of providing the 
DRM encoded content item in a plurality of respective DRM methods and that after the 
client sends an offer message to the target server containing a list of at least one 
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supported DRM method then the target server sends an answer message to the client 
containing a corresponding answer list 1) indicating whether each DRM method listed in 
the offer message is supported by the target server, and 2) providing a respective network 
address of a DRM license server for each supported DRM method. 

Lockhart relates to the delivery of permits for enabling protected content to be 
viewed. Using what it calls a "DRM agnostic clearing house", Lockhart provides permits 
across multiple DRM architectures (col. 3, lines 37-49 and col. 4, lines 5-13). It states 
that permits are digital devices that allow consumers to access protected content. Since 
the permit is separate from the actual encoded content that the consumer desires to view 
and since Lockhart's permit process is "agnostic" to the type of DRM, there is no 
automated selection or negotiation of the DRM method between a client and a target 
server in Lockhart. 

The rejection acknowledges that Lockhart fails to disclose an offer message to 
a target server containing a list of at least one supported DRM method. It relies on 
Haukka to allegedly teach such an offer message. However, Haukka is unrelated to 
transfer of content files protected by DRM. It is merely a security mechanism for 
authenticating users (i.e., determining whether to allow access to a system by a particular 
user) by setting up a security association between two entities. Therefore, combining the 
teaching of Haukka with Lockhart does not result in the creation of an offer message 
listing DRM methods supported by the client. Furthermore, there would be no motivation 
to list supported DRM methods in Lockhart based on the teaching of Haukka because 
Lockhart is agnostic with respect to an actual DRM architecture and therefore Lockhart 
would not use such information if it had it. 

The examiner commented that "Haukka is relied on for the teaching of creating 
an offer message listing DRM methods supported by the client (i.e., client sends a client 
list of support DRM methods (e.g., supported security mechanisms) to the server, see 
Haukka: 0028)." The examiner's argument assumes, erroneously and without support, 
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that a "security mechanism" used for authentication is suggestive of a DRM method for 
decrypting content. The security methods of Haukka specify a type of interaction 
between a client and server that is used to authenticate the client. Thereafter, the 
authenticated client is given an authenticated status. Authentication does not result in the 
enabling of the authenticated user for the decoding of encoded content. 

In the Advisory Action, the examiner stated that "it is proper to consider a 
security mechanism, which can be used for authentication or encryption purpose, to be 
equivalent with a DRM method." Haukka does not disclose either encryption or 
decryption. Neither these terms nor any similar concept are found in Haukka. It is 
improper to associate encoded content as used in this invention with the term "security 
mechanism" as it is used in Haukka. Since the rejection fails to provide any reasoning for 
why the security mechanism of Haukka should be considered to be equivalent with a 
DRM method, the cited references fail to suggest the claimed limitations. 

Lockhart and Haukka are further deficient in that they fail to either teach or 
suggest an answer message from the target server to the client which provides a 
respective network address of a DRM license server for each supported DRM method. 
There are no content files in Haukka, and therefore there is no license server. In 
Lockhart, the permit server is the license server. Since the client is already connected 
with the DRM agnostic clearinghouse, there would be no reason for a redundant re- 
transmission of the network address of a license server. There is only one license server 
in Lockhart, and no respective DRM license servers for different supported DRM 
methods. Furthermore, there is no reason why any other common knowledge of one 
skilled in the art (with or without the teachings of Lockhart and Haukka) would lead to 
the claimed invention. 

Haukka further fails to teach that the server informs the client of the types of 
"security mechanism" that are supported. The Haukka server merely picks a method and 
then uses it. In contrast, claim 1 recites that the server provides an answer message that 
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indicates whether each DRM method listed in the offer message is supported by the 
server. Then the client selects which one to use. Since the user of the content can make 
its own tradeoffs in determining which of the available DRM methods to use, the 
invention provides an additional benefit of user flexibility. Thus, the combination of 
Lockhart and Haukka fails to teach or suggest the claimed invention. 

The final rejection relies on Lockhart for disclosure of an answer message, 
stating that "Lockhart discloses web retailer provides consumer with a link specifies an 
Internet from which consumer may download and install permit." However, the claimed 
answer message includes an indication of whether each DRM method listed in the offer 
message is supported by the target server. The final rejection has not offered any 
reasoning for this recited limitation being taught or suggested by the cited references. 

Accordingly, the rejection of claim 1 should be reversed. 

Claim 13 

With respect to the claim limitations discussed above, claim 13 recites 
substantially identical limitations. For example, claim 13 recites, inter alia, that the target 
server is capable of providing the DRM encoded content item in a plurality of respective 
DRM methods and that after the software executed by the client sends an offer message 
to the target server containing a list of at least one supported DRM method then the client 
software receives an answer message containing a corresponding answer list 1) indicating 
whether each DRM method listed in the offer message is supported by the target server, 
and 2) providing a respective network address of a DRM license server for each 
supported DRM method. Therefore, claim 13 is allowable for the same reasons as 
discussed above with respect to claim 1, and the rejection of claim 13 should be reversed. 

CONCLUSION 
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The final rejection has failed to establish a case of prima facie obviousness of 



any of claims 1-7 and 13-16. The prior art relied upon in the final rejection neither 
teaches nor suggests the structure or function of the present invention nor does it provide 
any teaching which can obtain the significant advantages which are achieved by the 
present invention. Accordingly, the rejections contained in the final rejection dated June 
7, 2007, should be reversed. 



Date: November 1, 2007 
MacMillan, Sobanski & Todd, LLC 
One Maritime Plaza, Fourth Floor 
720 Water Street 
Toledo, Ohio 43604 
Tel: 734-542-0228 
Fax: 734-542-9569 



Respectfully submitted, 




Mark L. Mollon 
Registration No. 3 1 , 1 23 
Attorney for Appellant 
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CLAIMS APPENDIX 
Claims 1-7 and 13-16 now read as follows: 

1 . A method for initiating delivery of a digital rights management (DRM) 
encoded content item over a digital network between a client and a target server, said 
method comprising the steps of: 

said client identifying a link to said target server for accessing said DRM 
encoded content item, said target server being capable of providing said DRM encoded 
content item in a plurality of respective DRM methods; 

said client initiating a network session with said target server; 

said client sending an offer message to said target server containing a list of at 
least one supported DRM method; 

said target server sending an answer message to said client containing a 
corresponding answer list 1) indicating whether each DRM method listed in said offer 
message is supported by said target server, and 2) providing a respective network address 
of a DRM license server for each supported DRM method; 

said client selecting a supported DRM method from said answer list; 

said client obtaining a DRM license using said respective network address 
listed for said selected DRM method; and 

said target server delivering said DRM encoded content item to said client 
using said selected DRM method. 

2. The method of claim 1 wherein each said network address comprises a 
respective IP address and a respective port number for a respective DRM license server. 

3. The method of claim 1 wherein said answer message further includes a 
network transport method for each said supported DRM method. 
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4. The method of claim 1 wherein said answer message comprises a zero value 
for each DRM method not supported by said target server. 

5. The method of claim 1 wherein said offer message lists a plurality of DRM 
methods in order of preferred acceptance. 

6. The method of claim 5 wherein said selected DRM method is comprised of 
a DRM method supported by said target server that is listed earliest in said order of said 
offer message. 

7. The method of claim 1 wherein said offer message and said answer message 
are exchanged using a session description protocol. 

13. Software for distribution of digital rights management (DRM) encoded 
content items over a digital network between a client and a target server, wherein said 
target server is capable of providing said DRM encoded content item in a plurality of 
respective DRM methods, said software embodied on a computer readable medium and, 
when executed by said client, operable to perform the steps comprising: 

selecting a link to said target server for accessing a desired DRM encoded 
content item; 

initiating a network session with said target server; 

sending an offer message to said target server containing a list of at least one 
supported DRM method; 

receiving an answer message from said target server containing a 
corresponding answer list 1) indicating whether each DRM method listed in said offer 
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message is supported by said target server, and 2) providing a respective network address 
of a DRM license server for each supported DRM method; 

selecting a supported DRM method from said answer list; 

obtaining a DRM license using said respective network address listed for said 
selected DRM method; and 

retrieving said DRM encoded content item from said target server using said 
selected DRM method. 

14. The software of claim 13 operable to list a plurality of DRM methods in 
said offer message in order of preferred acceptance. 

15. The software of claim 14 operable to select a DRM method supported by 
said target server that is listed earliest in said order of said offer message. 

16. The software of claim 13 wherein said offer message and said answer 
message are exchanged using a session description protocol. 
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EVIDENCE APPENDIX 
No evidence has been submitted under 37 CFR §§1.130, §§1.131, §§1.132, 

otherwise. 

RELATED PROCEEDINGS APPENDIX 
There are no related proceedings and no corresponding decisions rendered. 
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